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interface IteratorCc : Collection, k : Fract> { 
states available, end refine alive 


boolean hasNext () : 


Collection c = new . . . 
Iterator it = c. iterator (); 

// legal 

pure(this) — ° ( result = true 0 pure(r/?/j) in available)) 
© ( result = false 0 pur e(this) in end) 

while (it .hasNext () && ...) { 

// legal 

Object nextO ; 

Object o = it. next (); 

// legal 

full(tfHj) in available — ° full (this) 

Iterator it2 = c. iterator (); 

// legal 

void finalize 0 ; 

while(it2. hasNext ()) { 

// legal 

unique^/jw) — o immutable(c, k) 

Object o2 - it2.next(); 

... > 

> 

if (it .hasNext () kb c.sizeO == 3) { 

// legal 

> 

// legal 

interface Collection { 

void add (Object o) : full(/to) — o full(//i/j) 

c .remove (it .next () ) ; 

// legal 

int size () : pur e(//iw) -© result > 0 ® pure(//iis) 

if (it .hasNext () ) ... } 

// ILLEGAL 

// remove() , containsO etc. similar 

Iterator it3 - c . iterator () ; 

// legal 



IteratorCihis , k> iterator() : 

immutable(f^/s, k) — o uniq ue(result) 

> 


FIG. 4 
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Collection c = new . . . unique(c) 

Iterator it<c, l/2> = c . iterator () ; 

immutable(c, 1/2) ® unique(rt) 
while (it .hasNext () && . ..) { 

immutable(c, 1/2) 0 unique(if) in available 
Object o = it.nextO; 

immutable(c, 1/2) 0 unique(iY) 
Iterator it2<c, l/4> - c . iterator () ; 

immutable(c, 1/4) 0 unique(z'r) 0 uniqu e(it2) 
while (it2 .hasNext () ) { 

immutable(c, 1/4) 0 unique(z7) (g> unique(z72) in available 
Object o2 = it2.next(); 

immutable(c, 1/4) <g> unique(zf) 0 unique(if2) 
... } // it2 dies 

> immutable(c, 1/2) 0 unique(zf) 

if (it .hasNext 0 && c.sizeO == 3) { 

immutable(c, 1/2) 0 unique(it) in available 
c . remove (it .next () ) ; // it dies after next () 

unique(c) and no permission for it 
if (it . hasNext ( ) ) ... > // ILLEGAL 

// it definitely dead unlque(c) 

Iterator it3<c, l/2> = c . iterator () ; 

immutable(c, 1/2) 0 unique(zYi) 

FIG. 6 



FIG. 7 


public class PipedOutputStream { 

states raw, open, closed refine alive; 
states ready, sending refine open; 

raw := sink — null 
ready := half(jwA, open) 
sending := sink null 
closed := sink ^ null 

private PipedlnputStream sink; 

public PipedOutputStreamO : 

1 — o uriique(//»‘j) in raw { } 

void connect (PipedlnputStream snk) : 
fu II ( 1 / 7 / 5 ) in raw 0 half^nAr, open) —o 
fullfr/z/y) in ready 

{ sink - snk; store permission in field 

> full(//j/5) in open 

public void vrite(int b) : 

full (this, open) in ready 0 b > 0 — 1 0 fuil(f/zz5, open) in ready 
{ half( 5 m£, open) from invariant 

sink .receive (b) ; returns half(5i>i/:, open) 

> full (f/275, open ) in ready 

public void closeQ : 

full(//j/5) in ready — o full(//n'5) in closed 
{ ha If (sink, open) from invariant 

sink .receivedLast () ; consumes half(5irtfc } open) 

> full (this) in closed 

} 


FIG. 8 
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class Pipedlnput Stream { 

stream = open, closed refines alive; 

position = within, eof refines open; 

buffer = empty, nonEmpty refines within; 

filling = partial, filled refines nonEmpty; 

source = sourceOpen, sourceClosed refines nonEmpty; 

empty := in < 0 ® closedByWriter = false 
partial := in > 0 ® in ^ out 
filled := in — out 

sourceOpen := closedByWriter = false 
sourceClosed := closedByWriter ® half(/Aw, open) 
eof ;= in < 0 ® closedByWriter ® ha If (/Aw, open) 

private boolean closedByWriter = false; 
private volatile boolean closedByReader = false; 
private byte buffer [] - new byte [1024] ; 
private int in = -1, out = 0; 

public Pip ed Input Str earn (PipedOutput Stream src) : 
full(jrc) in raw — o half(/Aw, open) ® full(^rc) in open 
{ unique(/Aw) in open ^ ha If (/Aw, open) ® half(/Aw, open) 
src . connect (this) ; consumes one half(/Aw, open) 

} half(/Aw, open) ® fullf.src) in open 

synchronized void receive (int b) : 

half(/Awj open) ® b > 0 — 1 o half(/Aw, open) in nonEmpty 
{ // standard implementation checks if pipe intact 
while (in == out) half(/Aw, open) in filled 

... // wait a second 

half(/Aw, open) in empty © partial 
if (in < 0) { in = 0; out - 0; } 
buffer [in++] (byte) (b k OxFF) ; 
if (in >= buff er. length) in = 0; 

} half(/Aw, open) in partial 

synchronized void receivedLast () : 
half(/Aw, open) — o 1 

{ closedByWriter - true; } this is now sourceClosed 

public synchronized int read() : 

share(/Aw, open) — o [result > 0 ® share(/Aw, open)) 

© ( result — -1 ® share(/Aw, open) in eof) 

{ ... > // analogous to receive 0 

public synchronized void close () : 

half(/Aw, open) in eof — « unique(/Aw) inclosed 
{ half(/Aw, open) from eof invariant ^ unique(/Aw, open) 

closedByReader = true; 
in = -1; 

> 

> 


FIG. 9 
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public abstract class InputStream { 
states open, closed refine alive; 
states within, eof refine open; 

public abstract int readO : 

share(r/»'5*>, open) — o [result >00 share^tef,-, open)) 

© ( result = -1 0 share [this< r , open) in eof) 
public abstract void close 0 : 

full(ftof r , alive) in open — o full(r/njf f , alive) in closed 

public int read(byte[] buf) : 
share(f/ti5, open) 0 buf £ null ~o 

(result = — 1 <S> s harefhis, open) in eof) © 

[result >00 shar e[this, open)) 

{ ... f or ( . . . ) 

. . . int c = this. readO . . . } 

> 

public class FilterlnputStream extends InputStream { 
within := umque(s) in within 
eof unique(s) in eof 
closed := unique(.s) in closed 

private volatile InputStream s; 

protected Filer InputStream (InputStream s) 

unique^, alive) in open — o unique(f/ziyf r , alive) in open 
{ this.s = s; } 

. * - // readO and closeQ forward to s 


FIG. 11 
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public class Buf f eredlnput Stream 
extends FilterlnputStream { 
states depleted, filled refine within; 

closed := unique^wp^r) in closed & buf — null 
open := uniqu z{buf) 

filled := pos < count ® unique(,yw/?er) in open 
depleted := pos > count ® unique^uper) in within 
eof ; = pos > count ® unique(jw/?er) in in eof 

private byte buf [] = new byte [8192]; 
private int count = 0, pos = 0; 

public Buff eredInputStreajn(InputStream s) 
unique^) in open — o un\que(thisf r ) in open 
{ count = pos = 0 ® uniq uQ(buf) 

super (s) ; uniqu e(super) in open 

> unique(/A/jf rj alive) in open 

public synchronized int readQ { 
if (pos >= count) 

{ share(fAi 5 f r , open) in depleted © eof 

fill O ; share(//?ii , f r , open) in filled ©eof 

if (pos >- count) 

return -1 ; returns share(f/?iyf f} open) in eof 

> any path; share(//f«f M open) in filled 

return buf[pos++] k OxFF; 

> $hare(/Atff r , open) in filled 0 eof 

private void fill() 

share(//7^f r , open) in depleted © eof — o 
share(// 2 ^f r , open) infilled © eof 
{ invariant: unique(jwper) in within © eof 

count = pos = 0; note: assumes buffer was fully read 
int b = super .readQ ; unique(^wper) in within © eof 
while (b >= 0) { unique($w/?er) in within 

buf[count++] = (byte) (b k OxFF); 

share(//»jf f) open) infilled 
if (count >= buf. length) break; 
b = super .read() ; unique(5w/?er) in within © eof 
} if loop never taken , share(i7j/jf r , open) in eof 

> sh a rents’, open) in filled © eof 

public synchronized void close () { 

buf = null; invariant; uniq ue(super) in open 

super , close () ; umque(.Si//?er) inclosed 

> fu I \fhisf r 3 alive) in dosed 


FIG. 12 
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FIG. 15 


class C extends C l { F R . . . } refinements^') = R' n i n refinements(C) 
refine merits (Object) = refinements(C) = R r } R C h n wf 

C I- -4i wf C }- A 2 wf C 1~ A\ wf Aj # A 2 C h A 2 wf d — s ref ines $ € refinements(C) q h n wf 
C h A\ © A 2 wf Oh Ai -<4.2 wf G h Si < d C h d < s C h n < n 
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C I - A \2 -< ft C b A\ ® A 2 wf C h A lt 2 -< fi. C h A\ ® A 2 VA C h A -< n Vn' : C H A ~< n' implies n < n' 

Ch A x ^A 2 -<n C f- A 1 © A 2 -< n ChA <C n 


FIG. 14 
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r h t : T r ; A h [t/x]P localFields(C) = f :T T; A h [Ji/x]P 

p-Term „ v, n . „ — „ ‘ P-FlELD 


r ; AI- 0 t:3x:TP T; A hg. f t : 3i : Ti.P 

r f F~r init(C) = a) r ; a f [t/j]P 

T] A b° new C(i) : 3x : C r .access(x. alive, {alive 1}, 1, A) 

(I\ t = true); A R d : 3x : T .P x \ € 1 
r h t : bool (r, t = false); A M e 2 : 3x : T.P 2 \ £2 

r ; A b iv J if (t, e u e 2 ) : 3x : T.P, © P 2 \ £ 1 U £ 2 

r ; A h £ ei : 3x : T.P \ £ x (I\x : T); (A', P) H e 2 : P 2 \ £ 2 
i = l implies no temporary assumptions in A * Fields in £\ do not occur in A' 


P-NEW 


P-If 


P-Let 

(x : T, this : C)\ P l-J^ e : ^result : T t .P t ® T \ £ E — 3 result : T r .P r override(ra, C, Vx : T.P — o P) 


r ; (A, A') l- lVjr let x = e x in e 2 : P 2 \ £1 U £ 2 


T r ra(T x) : P — o E = e ok in C 

Af ok in C M overrides all methods with this f r permissions in C f 
class C extends C' { F R I N M } ok 


P-METH 


P-Class 


CL ok ■ P e : E \ £ 
(ST, e) : E 


P-Prog 


FIG. 16 


class C extends C' {...} € CL class C {. . . M ■ . ■} € CL Tr m(T x) : P 3 result : T r .P' = e £ M 
C extends C / mtype(m, C) * Vx : T.P — o 3resu/r : T r .P' 

C extends C‘ mtype(m, C r ) = Vx : T.MS' implies (x : T, this : C); • h MS — o M5' class C . . . {P . . .} € CT 
override(ra, C, Vx : T.MS) localFields(C) = F 

class C extends C" {/ : T in n S initially (3/' : T r , f : T.P r <g> P, A) . . . } 
init(C / ) = (3/' : T.P', A') *; ( P, full (super, alive, {alive »-» l},i4 # ))h inv c (>l)®T 

init(Object) = (1, alive) tnit(C) = (3/' : T', / : T .P ; igi P, A) 

class C{...n = P...}ECl P = ® n '<n"<n pred c (n") inv c (A) = P =» n 7 

pred c (n) = P pred c (n',n) = P inv c (n,Fl) = P ® pred c (n', n) ® pred c (n) 

invc(^i) = Pi =» ft* pred c (rii,n) = P/ ni <S> n 2 jC n (i— 1,2) 
invc(n) = 1 =S> n invo(Ai <g) A 2 ) = Pi 0 P{ <S> P 2 P 2 =► n 


invc(Ai) = Pi => n x pred c (7it,n) = P( ni $ n 2 € n (* € 1, 2) 

i nv c(^i © -^2) = (Pi & P{) © (P2 ® n>)) ^ ^ 


only pure permissions in P exists share or full permission in P 

effects A I lowed (P) = 0 efFectsAllowed(P) = 1 


FIG. 17 
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invc(n, g, k, A) 
inv c (n, 0 ,O,A) 
where abovee(n) 


in v^(n, A) 0 purify(abovec(n)) 
purify (invc(n, A) 0 abovec(n)) 

®n':n<n'<aiiv e pred c (n') 


FIG. 18 


T\ A he access(//»' 5 f r , n, g, k, A) receiver packed 
k = 0 implies i = 0 F; (A 7 , inv c (n, g, fc, A), unpacked(n, g, k, A)) h l c e: E\£ 

T; (A, A 7 ) \- l c unpack(n, k, A) in e : E \ £ 


P-Unpack 


F; A he inve(n, g,k, A) 0 unpacked(n, g , /c, A 7 ) fc = 0 imp lies A = A 7 
T; (A 7 , access(f/2Z5f r , n, /c, A)) h^ e : E\£ localFields(C) = f T Inn Fields do not occur in A 7 

F; (A, A 7 ) hj~. pack n to A in e : E \ f 


T\~t 0 :Co Tht:T F; A h [t 0 /this][i 0 /thiSf r ][t/z]P 
mtype(m, Co) = Vx : T.P — o E i — efFectsAllowed(P) receiver packed 


F; A h l : [t 0 /this][*o/thisf r |[?/x]P 


P-Call 


r h t ; T F; A h [super/thiSf r ][t/x]P C extends C' 
mtype(7n, C') = Vx : T.P — o P i = efFectsAllowed (P) receiver packed 

F; A h^. super. ro(t) : [super/thisf r ][t/x]p 


r; A ht : 3x : Tj.P T; A 7 h c [/,/x 7 ]P 7 0 p 
localFields(C) = / : T in n n* < n p = unpacked(n, g : fc, A), A: / 0 

F ; (A, A 7 ) h^ assign := t : 3x 7 : Ti-P 7 0 [fi/x]P 0p \ 


P-ASSIGN 


FIG. 19 


p = access(r, re, ff , A, 4) purify^) = P' purify(P 2 ) = P£ ope{®,&,®} 
purify(p) = pure(r. n, g, A) purify(P] op P 2 ) = P' op P 2 

imit 6 {1, T, 0} purify(P) = P' purify(P) = P' 

purify (unit) = unit purify(3z : P.P) = 3 Z : JJ.P 1 purify (Vz : P.P) = V 2 : HP' 


-Pack 


FIG. 20 
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A — A' — A" or ( A — A! and A" = n) or (. A - A" and A! — n) 

access(r, n, g, k, A) access (r, n, p/ 2 , fc/ 2 , A') <g> access(r, n, 5/2, A;/2, A") 

A = A' = A" or (A = A' A" = n) or (A = A" and A' = n ) 

A.S Y 

access (r, n, ^,/c, A) access(r,n,^/2,fc, A') ® pure(r, n,^/2 5 A /y ) 

n\ # n 2 Ai -< ni < n A2 -< n 2 < n 
Pi = full(r. Hi, { g , nodes(ni, n) •— » 1 }/2, Ai) 

—7 F-Split-® 

full(r, n, g, A x <g> A 2 ) ^ pi ® P2 


ni # n,2 A\ -< ni < n A 2 -< n 2 < n 
pi = full(r, rii, (p, nwl, nodes(ni, n) •-» l}/2, A t ) 


Pi <8> p 2 ^ full(r, n, {g, n •-» 1 }, Aj <g> A 2 ) 

^i#A 2 

full (r,n,g,A 1 © A 2 ) full(r, n, g, Ai) ©full(r, n,g, A 2 ) 

A < n' <n „ ^ 

p-Dj 

full(r, n, <?, A) ^ full(r, n'. {5. nodes(n / , n) 1— > l}, A) 

A < r\! < n 


F-JOIN-® 


F-DOWN 


fullin'. {g,n 1— *■ 1, nodes(n',n) l}, A) ^ full(r,n, {5 , n >-> 1}, A) 


n' < n 

pure(r, n, {5, nodes(n', n) 1— > k}, A) ^ pur e(r,n' ,g, A) 


P-Up 


access(r, n, g. A) ^ access(r, n, g , n) 


Forget 


FIG. 21 
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class Buf f eredlnputStream extends FilterlnputStream { 
states ready, reads refine open; . . . 
states partial, complete refine filled; 

reads := reading ; ready := reading = false; . . . 

private boolean reading; . . . 

public int read() : V/c : Fract. . . . — 
unpack(open, k ) in 

let r = reading in if (r == false, ... fill() ... ) 

private bool fillO : Vfc : Fract. 
shareft/i/jf,, open) in depleted © eof — o 
share(r/iuf r , open) in available © eof = 
unpack(open, k , depleted © eof) in 

assign count = 0 in assign pos = 0 in 
assign reading = true in 
pack to reads in 

let b = super. read () in 
unpack(open, k, Open) in 

let r = reading in assign reading - false in 
assign count = 0 in assign pos = 0 in 
if(r, if (b = -1, pack to eof in false, 
pack to depleted in doFill(b)), 
pack to eof in false) 

private bool doFill(int b) : VA; : Fract. 
share(// 2 i'ff r , open) in depleted ffi partial — o 
share(r/ 2 Wf r , open) in partial © complete = 
unpack(open, k, depleted © partial) in 

let c = count in let buffer = buf in 
assign buffer [c] = b in assign count = c + 1 in 
let 1 = buf fer . length in 
if(c + 1 >= 1, pack to complete in true, 
assign reading = true in pack to reads in 
let b = super. read() in unpack(open, k) in 

let r = reading in assign reading = false in 
assign count = c + 1 in assign pos = 0 in 
pack to partial in 

if(r == false I I b == -1, true, doFill(b)) 


FIG. 22 
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METHOD FOR STATICALLY CHECKING AN 
OBJECT-ORIENTED COMPUTER PROGRAM 
MODULE 

This application claims the benefit of copending U.S. pro- 
visional application Ser. No. 60/919,252 filed Mar. 21, 2007, 
and entitled System for Tracking Typestate in Object-Ori- 
ented Languages With Aliasing, which is hereby incorporated 
in its entirety for all purposes. 

GOVERNMENT RIGHTS 

This invention was made with government support under 
NASA Grant No. NNA05CS30A, NSF Grant No. CCF- 
0546550, and DARPA Contract No. HR001 10710019. The 
government may have certain rights in this invention. 

BACKGROUND 

In object-oriented software, objects often define usage pro- 
tocols that clients must follow in order for these objects to 
work properly. Protocols essentially define legal sequences of 
method calls. In conventional object-oriented languages, 
developers have at least three ways of finding out about pro- 
tocols: reading informal documentation, receiving runtime 
exceptions that indicate protocol violations, or observing 
incorrect program behavior as a result of protocol violations 
that broke internal invariants. 

Aliasing, i.e., the existence of multiple references to the 
same object, is a significant complication in checking 
whether clients observe a protocol: a client does not neces- 
sarily know whether its reference to an object is the only 
reference that is active at a particular execution point. This 
also makes it difficult to check whether a class implements its 
specified protocol because reentrant callbacks through aliases 
can again lead to unexpected state changes. 

Existing protocol checking approaches fall into two cat- 
egories. They either operate globally, i.e., check an entire 
code base at once, or severely restrict aliasing. Global analy- 
ses typically account for aliasing, but they are not suitable for 
interactive use during development. Moreover, they do not 
check whether a declared protocol is implemented correctly, 
a crucial requirement in object-oriented software where any 
class might have a protocol of its own. 

Modular protocol checkers, like Fugue [12], the first sound 
modular typestate checker for an object-oriented language, 
better support developers while they write code: like a 
typechecker, they check each method separately for protocol 
violations while assuming the rest of the system to behave as 
specified. The trade-off, unfortunately, has been that modular 
checkers require code to follow pre-defined patterns of alias- 
ing. Once a program leaves the realm of supported aliasing, 
any further state changes are forbidden. Generally speaking, 
state changes are only allowed where the checker is aware of 
all references to the changing object. 

This approach has serious drawbacks. First, many 
examples of realistic code might be excluded. Moreover, 
from a developer’s point of view, the boundaries of what a 
checker supports are hard to predict, and they might not fit 
with the best implementation strategy for a particular prob- 
lem. Finally, aliasing restrictions arguably leave developers 
alone just when they have the most trouble in reasoning about 
their code, namely, in the presence of subtle aliasing. Thus, a 
need exists for a method of checking an object-oriented pro- 
gram module having objects having multiple references by 
code not available for analysis. 
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SUMMARY 

We have developed a sound modular protocol checking 
approach, based on typestates, that allows a great deal of 
5 flexibility in aliasing while guaranteeing the absence of pro- 
tocol violations at runtime. A main technical contribution is a 
novel abstraction, access permissions, that combines 
typestate and object aliasing information. In our methodol- 
ogy, developers express their protocol design intent through 
to annotations based on access permissions. Our checking 
approach then tracks permissions through method implemen- 
tations. For each object reference the checker keeps track of 
the degree of possible aliasing and is appropriately conserva- 
tive in reasoning about that reference. This helps developers 
15 account for object manipulations that may occur through 
aliases. The checking approach handles inheritance in a novel 
way, giving subclasses more flexibility in method overriding. 
Case studies on Java iterators and streams provide evidence 
that access permissions can model realistic protocols, and 
20 protocol checking based on access permissions can be used to 
reason precisely about the protocols that arise in practice. 

One embodiment of our disclosure is directed to a method 
for statically checking an object-oriented computer program 
module that includes the step of identifying objects within a 
25 computer program module, at least one of the objects having 
a plurality of references thereto, possibly from multiple cli- 
ents. A discipline of permissions is imposed on the objects 
identified within the computer program module. The permis- 
sions enable tracking, from among a discrete set of change- 
30 able states, a subset of states each object might be in. A 
determination is made regarding whether the imposed per- 
missions are violated by a potential reference to any of the 
identified objects. The results of the determination are output 
to a user. 

35 Another embodiment of our disclosure is directed to a 
method for statically checking an object-oriented computer 
program module, comprising identifying objects within a 
computer program module. The identified objects are parti- 
tioned into a plurality of dimensions, each dimension 
40 assigned to a client. Each client independently tracks, from 
among a discrete set of changeable states, a subset of states 
each object might be in within that client’s dimension. A 
discipline of permissions is imposed in which the operations 
that a client can invoke involving an obj ect are limited to those 
45 operations in which the invoked operation changes the state of 
the object only in that client’s dimension. A determination is 
made regarding whether the imposed permissions are vio- 
lated, and the results are output to the user. 

Another embodiment of our disclosure is directed to a 
50 method for statically checking an object-oriented computer 
program module, comprising identifying objects within a 
computer program module. A discipline of permissions is 
imposed to the objects identified within the computer pro- 
gram module such that for each object, only one client may 
55 have read/write permission to the object, track the object’s 
state from among a discrete set of changeable states, and 
perform any legal operation on the object given the object’s 
current state while all other clients may have read-only access 
to the object, and can perform only operations that do not 
60 affect the object’s state and are legal given the client’ s knowl- 
edge of the object’s current state. A determination is made 
regarding whether the imposed permissions are violated, and 
the results are output to the user. 

Another embodiment of our disclosure is directed to a 
65 method for statically checking an object-oriented computer 
program module, comprising identifying objects within a 
computer program module, where the objects have discrete 
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states that change perceptibly and non-monotonically within 
a guaranteed state space. A discipline of permissions is 
imposed to the objects identified within the computer pro- 
gram module such that a plurality of clients can each have a 
permis sion that enables tracking a subset of states each obj ect 5 
might be in. A determination is made regarding whether the 
imposed permissions are violated, and the results are output 
to the user. 

Another embodiment of our disclosure is directed to a 
method for statically checking an object-oriented computer 10 
program module, comprising identifying objects within a 
computer program module, at least one of the objects having 
a plurality of references thereto. A discipline of permissions is 
imposed to the objects identified within the computer pro- 
gram module that enables tracking, from among a discrete set 1 5 
of changeable states represented by a hierarchical state 
machine, a subset of states each object might be in. A deter- 
mination is made regarding whether the imposed permissions 
are violated, and the results are output to the user. 

Finally, another embodiment of our disclosure is directed 20 
to a method for statically checking an object-oriented com- 
puter program module, comprising identifying objects within 
a computer program module, at least one of the objects having 
a plurality of references thereto. A discipline of permissions is 
imposed to the objects identified within the computer pro- 25 
gram module that enables tracking, from among a discrete set 
of changeable states including a superclass state and a sub- 
class state which may differ, a subset of states each object 
might be in. A determination is made regarding whether the 
imposed permissions are violated, and the results are output 30 
to the user. 

This disclosure proposes a sound modular protocol check- 
ing approach, based on typestates, that allows a great deal of 
flexibility in aliasing. A novel abstraction, access permis- 
sions, combines typestate and object aliasing information. 35 
Developers express their protocol design intent using access 
permissions. Our checking approach then tracks permissions 
through method implementations. For each object reference 
the checker keeps track of the degree of possible aliasing and 
is appropriately conservative in reasoning about that refer- 40 
ence. A way of breaking an invariant in a frequently used Java 
standard library class was exposed in this way. The checking 
approach handles inheritance in a novel way, giving sub- 
classes more flexibility in method overriding. Case studies on 
Java iterators and streams provide evidence that access per- 45 
missions can model realistic protocols, and protocol checking 
based on access permissions can be used to reason precisely 
about protocols arising in practice. Note that only a fraction of 
our system’ s capabilities are needed for any given example 
(although they all are necessary in different situations). 50 
Those, and other advantages and benefits, will become appar- 
ent from the detailed description below. 

BRIEF DESCRIPTION OF THE FIGURES 

55 

For the present disclosure to be readily understood and 
easily practiced, the present disclosure will now be described, 
for purposes of illustration and not limitation, in connection 
with the following figures, wherein: 

FIG. 1 is a flow chart illustrating our disclosed method; 60 

FIG. 2 illustrates our access permission taxonomy; 

FIG. 3 illustrates a read-only Iterator state machine proto- 
col; 

FIG. 4 is an example of a simple Iterator client; 

FIG. 5 illustrates a read-only Iterator and partial Collection 65 
interface specification; 

FIG. 6 is an example verifying a simple Iterator client; 
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FIG. 7 illustrates a PipedlnputStream’s state space (inside 
open); 

FIG. 8 illustrates a Java PipedOutputStream (simplified); 
FIG. 9 illustrates a Java PipedlnputStream (simplified); 
FIG. 10 illustrates frames of a BufferedlnputStream 
instance in state filled. The shaded virtual frame is in a dif- 
ferent state than its super- frame; 

FIG. 11 illustrates a Java FilterlnputStream that forwards 
all calls to underlying InputStream (simplified); 

FIG. 12 illustrates how BufferedlnputStream caches char- 
acters from FilterlnputStream base class; 

FIG. 13 illustrates an example of core language syntax. 
Specifications (I, N, MS) in FIG. 15; 

FIG. 14 illustrates state space judgments (assumptions A 
defined in FIG. 15): 

FIG. 15 illustrates an example of permission-based speci- 
fications; 

FIG. 16 Illustrates a permission checking for expressions 
(part 1) and declarations; 

FIG. 17 illustrates protocol verification helper judgments; 
FIG. 18 illustrates invariant construction (purify in FIG. 
20 ); 

FIG. 19 illustrates permission checking for expressions 
(part 2); 

FIG. 20 illustrates permission purification; 

FIG. 21 illustrates splitting and joining of access permis- 
sion; 

FIG. 22 illustrates a fragment of BufferedlnputStream 
from FIG. 12 in core language. 

DETAILED DESCRIPTION 
1 . Introduction 

This disclosure will help developers follow protocols while 
they write code as well as allow developers to correctly and 
concisely document protocols for their code. We build on our 
previous work on leveraging typestates [34] for lightweight 
object protocol specification [4]. Our protocols are state 
machines that are reminiscent of Statecharts [20]. 

Turning to FIG. 1, a method 10 for statically checking an 
object-oriented computer program module according to the 
present disclosure is illustrated. The method is comprised of 
step 12 in which objects within a computer program module 
are identified. At least one of the objects has a plurality of 
references thereto which may be from independent clients. 

In step 14, a discipline of permissions is imposed on the 
objects identified in step 12. The permissions, discussed in 
detail below, may be selected from the group consisting of: 
a permission allowing a read-only reference to an object, 
where other references can read and write to the object; 

a permission allowing a read/write reference to an object, 
where all other references to the object are read-only; 

a permission allowing a read-only reference to an object, 
where all other references to the object are also read-only; 
a permission allowing a single reference to an object; and 
a permission allowing a read/write reference to an object, 
where other references to the object can also be read/write 
references. 

The permissions may be imposed in a manner that allows 
the permissions to be associated with a fraction of an object. 
The permissions enable tracking, from among a discrete set of 
changeable states, a subset of states each object might be in. 

Computer programs always describe how objects go from 
one discrete “state” to another, because computers operate on 
the very large but still discrete states expressible in their 
physical memory. Likewise, any formal description of a pro- 
gram will be in terms of such states. The problem here is that 
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“state” is used differently in different contexts. It can refer to 
all the data associated with an object (or some abstraction 
thereof), but we mean in this disclosure “abstract” states that 
are the creation of the programmers which can be organized 
to describe a finite-state machine. We give programmers the 
opportunity to write these “abstract” states down and define 
how objects change from one of these states to another. We do 
this to capture legal sequences of events (states). Conversely, 
the actual code describes how the objects’ data changes over 
time. Our method associates each “abstract” state with a 
description of the data that may be associated with the object 
in that “abstract” state. Our method tracks what subset of 
these “abstract” states each object might be in, but it does not 
directly track how object data changes over time — that is 
tracked only indirectly, through the description of data asso- 
ciated with each “abstract” state. 

It is assumed that the states will change non-monotonically 
within a guaranteed state space. The states may be repre- 
sented by a hierarchical state machine. Additionally, objects 
having a superclass and subclass are allowed to have different 
states for each. 

The method of FIG. 1 continues with step 16 in which a 
determination is made regarding whether any of the imposed 
permissions is violated by a potential reference to one of the 
identified objects. Thereafter, at step 18, the results from step 
16 are output. 

The method illustrated in FIG. 1 is a sound, modular, 
typestate checking approach for Java-like object-oriented 
languages that allows a great deal of flexibility in allowing for 
aliased objects. For each reference, it tracks the degree of 
possible aliasing, and is appropriately conservative in reason- 
ing about that reference. This helps developers account for 
object manipulations that may occur through aliases. High 
precision in tracking effects of possible aliases together with 
systematic support for dynamic state tests, i.e., runtime tests 
on the state of objects, make this approach feasible. Our 
approach helped expose a way of breaking an internal invari- 
ant that causes a commonly used Java standard library class, 
java. io. BufferedlnputStream, to access an array outside its 
bounds. 

The method of FIG. 1 incorporates a novel abstraction, 
called access permissions (or simply permissions), that com- 
bines typestate with aliasing information about objects. 
Developers use access permissions to express the design 
intent of their protocols in annotations on methods and 
classes. Our modular checking approach verifies that imple- 
mentations follow this design intent. 

Access permissions systematically capture different pat- 
terns of aliasing (FIG. 2). A permission tracks (a) how a 
reference is allowed to read and/or modify the referenced 
object, (b) how the object might be accessed through other 
references, and (c) what is currently known about the object’ s 
typestate. 

In particular, our full and pure permissions [3] capture the 
situation where one reference has exclusive write access to an 
object (a full permission) while other references are only 
allowed to read from the same object (using pure permis- 
sions). Read-only access through pure permissions is intu- 
itively harmless but to our knowledge has not been exploited 
in existing modular protocol checkers. 

To increase precision of access permissions, we include 
two additional novel features, which make weak permissions 
more useful than in existing work. We call permissions 
“weak” if the referenced object can potentially be modified 
through other permissions. 
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Temporary state information can be associated with weak 
permissions. Our checking approach makes sure that tempo- 
rary state information is “forgotten” when it becomes out- 
dated. 

5 Permissions can be confined to a particular part of the 
referenced object’s state. This allows separate permissions to 
independent parts of the same object. It also implies a state 
guarantee even for weak permissions, i .e., a guarantee that the 
referenced object will not leave a certain state, 
to We handle inheritance in a novel way, giving subclasses 
more flexibility in method overriding. This is necessary for 
handling realistic examples of inheritance such as Java’s 
BufferedlnputStream (details in section 3.2). 

We validated the method set forth in FIG. 1 with two case 
15 studies, iterators (section 2) and streams (section 3) from 
Sun’s Java standard library implementation. These case stud- 
ies provide evidence that access permissions can model real- 
istic protocols, and protocol checking based on access per- 
missions can be used to reason precisely about the protocols 
20 that arise in practice. 

The evaluation herein does establish that our — compared 
to full-fledged program verification systems [26, 2] — rela- 
tively simple method of FIG. 1 can verify code idioms and 
find errors that no other decidable modular system can. The 
25 case studies reflect actual Java standard library protocols and, 
as far as presently known, cannot be handled by any existing 
modular protocol verification system. 

The following two sections introduce access permissions 
and a verification approach with examples from our case 
30 studies before sections 4 and 5 give a formal account of our 
approach. Section 6 compares our approach to related work. 

2. Read-Only Iterators 

This section illustrates basic protocol specification and 
verification using our approach based on a previous case 
35 study on Java iterators [3]. Iterators follow a straightforward 
protocol but define complicated aliasing restrictions that are 
easily violated by developers. They are therefore a good 
vehicle to introduce our approach to handling aliasing in 
protocol verification. Iterators as presented here cannot be 
40 handled by existing modular typestate checkers due to their 
aliasing restrictions. 

2.1 Specification Goals 

The material presented in this section models the Iterator 
interface defined in the Java standard library. For the sake of 
45 brevity, we focus on read-only iterators, i.e., iterators that 
cannot modify the collection on which they iterate. We will 
refer to read-only iterators simply as “iterators” and qualify 
full Java iterators as “modifying iterators.” In earlier work we 
showed how to capture full Java iterators [3]. Goals of the 
50 presented specification include the following. 

Capture the usage protocol of Java iterators. 

Allow creating an arbitrary number of iterators over col- 
lections. 

Invalidate iterators before modification of the iterated col- 
55 lection. 

2.2 State Machine Protocol 

An iterator returns all elements of an underlying collection 
one by one. Collections in the Java standard library are lists or 
sets of objects. Its interface includes methods to add objects, 
60 remove objects, and test whether an object is part of the 
collection. The interface also defines a method iterator that 
creates a new iterator over the collection. Repeatedly calling 
next on an iterator returns each object contained in the iterated 
collection exactly once. The method hasNext determines 
65 whether another object is available or the iteration reached its 
end. It is illegal to call next once hasNext returns false. FIG. 
3 illustrates this protocol as a simple state machine. 
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Notice that hasNext is legal in both states but does not 
change state. We call hasNext a dynamic state test: its return 
value indicates what state the iterator is currently in. The next 
section will show how this protocol can be specified. 

2.3 Iterator Interface Specification 5 

States Through Refinement. We call the set of possible 
states of an object its state space and define it as part of the 
object’s interface. As suggested above, we can model the 
iterator state space with two states, available and end. In our 
approach, states are introduced by refinement of an existing to 
state. State refinement corresponds to OR- states in Stat- 
echarts [20] and puts states into a tree hierarchy. 

State refinement allows interfaces to, at the same time, 
inherit their supertypes’ or superclass state spaces, define 
additional (more fine-grained) states, and be properly substi- 15 
tutable as subtypes of extended interfaces [4]. Refinement 
guarantees that all new states defined in a subtype correspond 
to a state inherited from the supertype. States form a hierarchy 
rooted in a state alive defined in the root type Object. Iterators 
therefore define their state space as follows. 20 

states available, end refine alive; 

Typestates do not correspond to fields in a class. They 
describe an object’s state of execution abstractly, and infor- 
mation about fields can be tied to typestates using state invari- 
ants (see section 3.1). 25 

Access Permissions Capture Design Intent. Iterators have 
only two methods, but these have very different behavior. 
While next can change the iterator’s state, hasNext only tests 
the iterator’s state. And even when a call to next does not 
change the iterator’s state, it still advances the iterator to the 30 
next object in the sequence. hasNext, on the other hand, is 
pure: it does not modify the iterator at all. 

We use a novel abstraction, access permissions (“permis- 
sions” for short), to capture this design intent as part of the 
iterator’s protocol. Permissions are associated with object 35 
references and govern how objects can be accessed through a 
given reference [7] . For next and hasNext, we only need two 
kinds of permissions; more kinds of permissions will be intro- 
duced later. 

full permissions grant read/write access to the referenced 40 
object and guarantee that no other reference has read/write 
access to the same object. 

pure permissions grant read-only access to the referenced 
object but assume that other permissions could modify the 
object. 45 

A distinguished full permission can coexist with an arbi- 
trary number of pure permissions to the same object. This 
property will be enforced when verifying protocol compli- 
ance. In a specification, we write perm(x) for a permission to 
an object referenced by x, where perm is one of the permis- 50 
sion kinds. Access permissions carry state information about 
the referenced object. For example, “full(this) in available” 
represents a full permission for an object (this) that is in the 
available state. 

Linear Logic Specifications. Methods can be specified 55 
with a state transition that describes how method parameters 
change state during method execution. We previously argued 
that existing typestate verification approaches are limited in 
their ability to express realistic state transitions [4] and pro- 
posed to capture method behavior more precisely with logical 60 
expressions. 

Access permissions represent resources that have to be 
consumed upon usage — otherwise permissions could be 
freely duplicated, possibly violating other permissions’ 
assumptions. Therefore, we base our specifications on linear 65 
logic [18]. Pre- and post-conditions are separated with a 
linear implication (-o) and use conjunction (x) and disjunc- 
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tion ©). “Tensor” (x) corresponds to conjunction, “alterna- 
tive” (®) to disjunction, and “lollie” (-o) to implication in 
conventional logic. The key difference is that linear logic 
treats known facts as resources that are consumed when prov- 
ing another fact. This fits well with our intuition of permis- 
sions as resources that give access to objects. In certain cases, 
internal choice (&, also called additive conjunction) has been 
useful [3]. These connectives represent the decidable multi- 
plicative-additive fragment of linear logic (MALL). 

Iterators illustrate that state transitions are often non-deter- 
ministic. For next, we can use an imprecise post-condition 
and specify next so that it requires a hill permission in state 
available and returns the full permission in the alive state. In 
a Statechart, this corresponds to transitioning to a state that 
contains sub states (FIG. 3). 

full(this) in available -o full(this) in alive 

Dynamic state tests (like hasNext) require relating the 
(Boolean) method result to the state of the tested object (usu- 
ally the receiver). A disjunction of conjunctions expresses the 
two possible outcomes of hasNext (FIG. 5) where each con- 
junction relates a possible method result to the corresponding 
receiver state. (We adopt the convention that (-o) binds 
weaker than (x) and (®).) 

pure(this) -o (result=true (x) pure(this) in available) 

® (result=false (x) pure (this) in end) 

These specifications enforce the characteristic hasNext/ 
next call pairing; hasNext determines the iterator’s current 
state. If it returns true then it is legal to call next. The iterator 
is in an unknown state after next returns, and another hasNext 
call determines the iterator’s new state. 

2.4 Creating and Disposing Iterators 

Multiple (independent) iterators are permitted for a single 
collection at the same time. However, the collection must not 
be modified while iteration is in progress. Standard imple- 
mentations try to detect such situations of concurrent modi- 
fication on a best-effort basis. But, ultimately, Java program- 
mers have to make sure on their own that collections are not 
modified while iterated. (Note that “concurrent” modifica- 
tions often occur in single-threaded programs [32].) 

This section shows how the aliasing constraints between 
iterators and its collection can be handled. As we will see, this 
problem is largely orthogonal to specifying the relatively 
simple protocol for individual iterators that was discussed in 
the previous section. 

Immutable Access Prevents Concurrent Modification. 
Access permissions can guarantee the absence of concurrent 
modification. The key observation is that when an iterator is 
created it stores a reference to the iterated collection in one of 
its fields. This reference should be associated with a permis- 
sion that guarantees the collection’s immutability while itera- 
tion is in progress. We include two previously proposed per- 
missions [6] into our system in order to properly specify 
collections. 

immutable permissions grant read-only access to the ref- 
erenced object and guarantee that no reference has read/write 
access to the same object. 

unique permissions grant read/write access and guarantee 
that no other reference has any access to the object. 

Thus immutable permissions cannot co-exist with full per- 
missions to the same object. We can specify the collection’s 
iterator method using these permissions as follows. Notice 
how it consumes or captures the incoming receiver permis- 
sion and returns an initial unique permission to a fresh iterator 
object. 

public class Collection { 

Iterator iterator (): immutable(this) -o unique(result)} 
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It turns out that this specification precisely captures Sun’s 
Java standard library implementation of iterators: Iterators 
are realized as inner classes that implicitly reference the col- 
lection they iterate. 

Permission Splitting. Consider a client such as the one in 5 
FIG. 4 . It gets a unique permission when first creating a 
collection. Then it creates an iterator which captures an 
immutable permission to the collection. However, the client 
later needs more immutable permissions to create additional 
iterators. Thus, while a unique permission is intuitively stron- 
ger than an immutable permission, we cannot just coerce the 
client’s unique permission to an immutable permission and 
pass it to iterator: it would get captured by the newly created 
iterator, leaving the client with no permission to the collection 1 5 
at all. 

To avoid this problem we use permission splitting in our 
verification approach. Before method calls we split the origi- 
nal permission into two, one of which is retained by the caller. 
Permissions are split so that their assumptions are not vio- 20 
lated. In particular, we never duplicate a full or unique per- 
mission and make sure that no hill permission co-exists with 
an immutable permission to the same object. Some of the 
legal splits are the following. 

unique(x)^ full(x)(x) pure(x) 25 

full(x)^ immutable(x)(x) immutable(x) 
immutable(x)^ inmiutable(x)(x) immutable(x) 
immutable(x)^ innnutable(x)(x) pure(x) 

They allow the example client in FIG. 4 to retain an immu- 
table permission when creating iterators, permitting multiple 30 
iterators and reading the collection directly at the same time. 

Permission Joining Recovers Modifying Access. When 
splitting a full permission to a collection into immutable 
permissions we lose the ability to modify the collection. 
Intuitively, we would like to reverse permission splits to 35 
regain the ability to modify the collection. 

Such permission joining can be allowed if we introduce the 
notion of fractions [6]. Essentially, fractions keep track of 
how often a permission was split. This later allows joining 
permissions (with known fractions) by putting together their 40 
fractions. A unique permission by definition holds a full frac- 
tion that is represented by one (1). We will capture fractions as 
part of our permissions and write (perm) (x, k) for a given 
permission with fraction k. We usually do not care about the 
exact fraction and therefore implicitly quantify over all frac- 45 
tions. If a fraction does not change, we often will omit it. 
Fractions allow us to define splitting and joining rules as 
follows: 

unique(x, l)^full(x, V 2 )(x) pure(x, Vi) 

full(x, k) ^ immutable(x, k/2)(x) immutable(x, k/2) 50 

immutable(x, k) immutable(x, k/2)(x) Immutable(x, 
k/2) 

immutable(x, k) && immutable(x, k/2)(x) pure(x, k/2) 

For example, we can split full(it, Vi) into full(it, Vi)(x) 
pure(it, Vi) and recombine them. Such reasoning lets our 55 
iterator client recover a unique iterator permission after each 
call into the iterator. 

Recovering Collection Permissions. Iterators are created 
by trading a collection permission for a unique iterator per- 
mission. We essentially allow the opposite trade as well to 60 
modify a previously iterated collection again. We can safely 
consume a unique iterator permission and recover the permis- 
sions to its fields because no reference will be able to access 
the iterator anymore. A simple live variable analysis can 
identify when variables with unique permissions are no 65 
longer used. (As a side effect, a permission-based approach 
therefore allows identifying dead objects.) 
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For lack of a more suitable location, we annotate the final- 
ize method to indicate what happens when an iterator is no 
longer usable. And to re-establish exactly the pennission that 
was originally passed to the iterator we parameterize Iterator 
objects with the collection permission’s fraction. The finalize 
specification can then release the captured collection permis- 
sion from dead iterators. The complete specification for itera- 
tors and a partial collection specification are summarized in 
FIG. 5 

2.5 Client Verification 

FIG. 6 illustrates how our client from FIG. 4 can be verified 
by tracking permissions and splitting/joining them as neces- 
sary. After each line of code, we show the current set of 
permissions on the right-hand side of the figure. We recover 
collection permissions from dead iterators as soon as pos- 
sible. This lets us verify the entire example client. We cor- 
rectly identify the seeded protocol violation. 

2.6 Summary 

We presented a specification of read-only iterators that 
prevents concurrent collection modification. To this end, it 
associates collections and iterators with access permissions, 
defines a simple state machine to capture the iterator usage 
protocol, and tracks pennission information using a decid- 
able fragment of linear logic. Our logic-based specifications 
can relate objects to precisely specify method behavior in 
terms of typestates and support reasoning about dynamic 
tests. 

3. Java Stream Implementations 

I/O protocols are common examples for typestate-based 
protocol enforcement approaches [11, 12, 4]. This section 
summarizes a case study in applying our approach to Java 
character streams and, in particular, stream pipes and buffered 
input streams. The section focuses on implementation verifi- 
cation of stream classes, which — to our knowledge — has not 
been attempted with typestates before. Implementation veri- 
fication generalizes techniques shown in the previous section 
for client verification. 

3.1 Stream Pipes 

Pipes are commonly used in operating system shells to 
forward output from one process to another process. Pipes 
carry alphanumeric characters for a source to a sink. The Java 
I/O library includes a pair of classes, PipedOutputStream and 
PipedlnputStream, that offers this functionality inside Java 
applications. This section provides a specification for Java 
pipes and shows how the classes implementing pipes in the 
Java standard library can be checked using our approach. 

Informal Pipe Contract. In a nutshell, Java pipes work as 
follows: A character-producing “writer” writes characters 
into a PipedOutputStream (the “source”) that forwards them 
to a connected PipedllnputStream (the “sink”) from which a 
“reader” can read them. The source forwards characters to the 
sink using the internal method receive. The writer calls close 
on the source when it is done, causing the source to call 
receivedLast on the sink (FIG. 8). 

The sink caches received characters in a circular buffer. 
Calling read on the sink removes a character from the buffer 
(FIG. 9). Eventually the sink will indicate, using an end of file 
token (EOF, -1 in Java), that no more characters can be read. 
At this point the reader can safely close the sink. Closing the 
sink before EOF was read is unsafe because the writer may 
still be active. 

The pipe classes in Sun’s standard library implementation 
have built-in runtime checks that throw exceptions in the 
following error cases: (1) closing the sink before the source, 
(2) writing to a closed source or pushing characters to the sink 
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after the source was closed, and (3) reading from a closed 
sink. The specification we present here makes these error 
cases impossible. 

State Space with Dimensions. The source protocol can be 
modeled with three states: raw, open, and closed, “raw” indi- 
cates that the source is not connected to a sink yet. For 
technical reasons that are discussed below, we refine open 
into ready and sending. The writer will always find the source 
in state ready. 

For the sink protocol, we again distinguish open and 
closed. A refinement of open helps capturing read’s protocol. 
The sink is within as long as read returns characters; the eof 
state is reached when read returns the EOF token. While 
within, we keep track of the sink’s buffer being empty or 
nonEmpty. We further refine nonempty into partial and filled, 
the latter corresponding to a full buffer. 

At the same time, however, we would like to track whether 
the source was closed, i.e., whether receivedLast was called. 
We previously proposed state dimensions to address such 
separate concerns (here, the buffer filling and the source state) 
[4] with states that are independent from each other. State 
dimensions correspond to AND-states in Statecharts [20]. 

We can simply refine nonEmpty twice, along different 
dimensions. We call the states for the second dimension 
sourceOpen and sourceClosed with the obvious semantics. 
Note that we only need the additional source dimension while 
the buffer is non Empty; the source is by definition open 
(closed) in the empty (eof) state. This is only one way of 
specifying the sink. It has the advantage that readers need not 
concern themselves with the internal communication 
between source and sink. To better visualize the sink’s state 
space, FIG. 7 summarizes it as a Statechart. 

Shared Modifying Access. Protocols for source and sink 
are formalized in FIGS. 8 and 9 with specifications that work 
similar to the iterator example in the last section. However, 
the sink is conceptually modified through two distinct refer- 
ences, one held by the source and one held by the reader. To 
capture this, we introduce our last permission. 

Share permissions grant read/write access to the referenced 
object but assume that other permissions have read/write 
access as well. 

Conventional programming languages effectively always 
use share permissions for mutable state. Interestingly, share 
permissions are split and joined exactly like immutable per- 
missions. Because share and immutable permissions cannot 
coexist, our rules force a commitment to either one when 
initially splitting a full permission. 

fiill(x, k)<5* share(x, k/2)© share(x, k/2) 
share(x, k) ^ share(x, k/2)© share(x, k/2) 
share(x, k) share(x, k/2)© pure(x, k/2) 

State Guarantees. We notice that most modifying methods 
cannot change a stream’s state arbitrarily. For example, read 
and receive will never leave the open state, and they cannot 
tolerate other permissions to leave open. 

We make this idea part of our access permissions. We 
include another parameter into permissions that specifies a 
state guarantee, i.e., a state that cannot be left even by modi- 
fying permissions. Thus a state guarantee (also called the 
permission’s root) corresponds to an “area” in a Statechart 
that cannot be left. As an example, we can write the permis- 
sion needed for read as share(this, open). Without an explicit 
state guarantee, only alive is guaranteed (this is what we did 
for iterators). 

State guarantees turn out to be crucial in making share and 
pure permissions useful because they guarantee a state even 
in the face of possible changes to the referenced object 
through other permissions. Moreover, if we combine them 
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with state dimensions, we get independent permissions for 
orthogonal object aspects that, e.g., let us elegantly model 
modifying iterators [3] . 

Explicit Fractions for Temporary Heap Sharing. When 
5 specifying the sink methods used by the source (receive and 
receivedLast), we have to ensure that the source can no longer 
call the sink after receivedLast so the sink can be safely 
closed. Moreover, to close the sink, we need to restore a 
permission rooted in alive. Thus the two share permissions for 
to the sink have to be joined in such a way that there are defi- 
nitely no other permissions relying on open (such permis- 
sions, e.g., could have been split off of one of the share 
permissions). 

We extend the notion of fractions to accomplish this task. 
15 We use fractions to track, for each state separately, how many 
permissions rely on it. What we get is a fraction function that 
maps guaranteed states (i.e., the permission’s root and its 
super-states) to fractions. For example, if we split an initial 
unique permission for a PipedlnputStream into two share 
20 permissions guaranteeing open then these permissions rely 
on open and alive with a Vi fraction each. (Iterator permis- 
sions root in alive and their fraction functions map alive to the 
given fraction.) 

To close the sink, we have to make sure that there are 
25 exactly two share permissions relying on open. Fraction func- 
tions make this requirement precise. For readability, we use 
the abbreviation half in FIG. 9 that stands for the following 
permission. 

half(x, open)=share(x, open, {alive I ^ l A, open 
!-> * 4 }) 

By adding fractions and moving the state guarantee up in 
the state hierarchy, the initial permission for the sink, unique 
(this, alive, {alive I — > 1 }), can be regained from two half(this, 
35 open) permissions; half is the only permission with an explicit 
fraction function. All other specifications implicitly quantify 
over all fraction functions and leave them unchanged. 

State Invariants Map Typestates to Fields. We now have a 
sufficient specification for both sides of the pipe. To verify 
40 their implementations we need to know what typestates cor- 
respond to in implementations. Our implementation verifica- 
tion extends Fugue’s approach of using state invariants to 
map states to predicates that describe the fields of an object in 
a given state [12]. We leverage our hierarchical state spaces 
45 and allow state invariants for states with refinements to cap- 
ture invariants common to all sub states of a state. 

FIG. 8 shows that the source’s state invariants describe its 
three states in the obvious way based on the field snk pointing 
to the sink. Notice that the invariant does not only talk about 
50 the sink’s state (as in Fugue) but uses permissions to control 
access through fields just as through local variables. 

The sink’s state invariants are much more involved (FIG. 9) 
and define, e.g., what the difference between an empty buffer 
(in <0) and a filled circular buffer (in=out) is. Interestingly, 
55 these invariants are all meticulously documented in the origi- 
nal Java standard library implementation for Pipedlnput- 
Stream [4]. The half permission to itself that the sink tempo- 
rarily holds for the time between calls to receivedLast and 
close lets us verify that close is allowed to close the sink. 

60 Verification with Invariants. Implementation checking 
assumes state invariants implied by incoming permissions 
and tracks changes to fields. Objects have to be in a state 
whenever they yield control to another object, including dur- 
ing method calls. For example, the source transitions to send- 
65 ing before calling the sink. However, the writer never finds the 
source in the sending state but always ready-sending never 
occurs in a method specification. We call states that are not 
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observed by a client intermediate states. They help us deal 
with re-entrant calls (details in section 5.2). A practical syntax 
could make such intermediate states implicit. 

FIGS. 8 and 9 show how implementation checking pro- 
ceeds for most of the source’s and sink’s methods. We show 
in detail how field assignments change the sink’s state. The 
sink’ s state information is frequently a disjunction of possible 
states. Dynamic tests essentially rule out states based on 
incompatible invariants. All of these tests are present in the 
original Java implementation; we removed additional non- 
null and state tests that are obviated by our approach. This not 
only shows how our approach forces necessary state tests but 
also suggests that our specifications could be used to generate 
such tests automatically. 

3.2 Buffered Input Streams 

A BufferedlnputStream (or “buffer,” for short) wraps 
another “underlying” stream and provides buffering of char- 
acters for more efficient retrieval. We will use this example to 
illustrate our approach to handling inheritance. Compared to 
the original implementation, we made fields “private” in 
order to illustrate calls to overridden methods using super. We 
omit intermediate states in this specification. 

Class Hierarchy. BufferedlnputStream is a subclass of Fil- 
terlnputStream, which in turn is a subclass of InputStream. 
InputStream is the abstract base class of all input streams and 
defines their protocol with informal documentation that we 
formalize in FIG. 11. It implements convenience methods 
such as read (int [ ]) in terms of other-abstract-methods. 
FilterlnputStream holds an underlying stream in a field s and 
simply forwards all calls to that stream (FIG. 11). Buffered- 
lnputStream overrides these methods to implement buffering. 

Frames. The buffer occasionally calls overridden methods 
to read from the underlying stream. Our approach is based on 
Fugue’s frames for reasoning about inheritance [12]. Objects 
are broken into frames, one for each class in the object’s class 
hierarchy. A frame holds the fields defined in the correspond- 
ing class. We call the frame corresponding to the object’s 
runtime type the virtual frame, referred to with normal refer- 
ences (including this). Relative to a method, we call the cur- 
rent frame — corresponding to the class that the method is 
defined in — with this^” and the frame corresponding to the 
immediate superclass is called super frame. FIG. 10 shows a 
sample BufferedlnputStream instance with its three frames. 

Frame Permissions. In our approach, a permission actually 
grants access to a particular frame. The permissions we have 
seen so far give a client access to the referenced object’s 
virtual frame. Permissions for other frames are only acces- 
sible from inside a subclass through super. 

FIG. 10 illustrates that a BufferedlnputStream ’s state can 
differ from the state its filter frame is in. The filter’s state 
might be eof (when the underlying stream reaches eof) while 
the buffer’s is still within (because the buffer array still holds 
unread characters). The state invariants in FIG. 12 formalize 
this. They let us verify that super calls in the buffer imple- 
mentation respect the filter’s protocol. 

Because the states of frames can differ it is important to 
enforce that a permission is only ever used to access fields in 
the frame it grants permission to. In specifications we specifi- 
cally mark permissions that will actually access fields (and 
not just call other methods) of the receiver with this /r . We 
require all methods that use these permissions to be overrid- 
den. On the other hand, convenience methods such as read (int 
[ ]) can operate with permissions to the virtual frame and need 
not be overridden (FIG. 11). 

This distinction implies that fill (FIG. 12) cannot call read 
(int [ ]) (because it does not have a suitable virtual frame 
permission) but only super. read( ). This is imperative for the 
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correctness of fill because a dynamically dispatched call 
would lead back into the — still empty — buffer, causing an 
infinite loop. (One can trigger exactly this effect in the Java 6 
implementation of BufferedlnputStream.) 

5 3.3 Summary 

This section showed how our approach can be used to 
verily realistic Java pipe and buffered input stream imple- 
mentations. The notion of access permissions is central to our 
approach. Overall, we introduced five different kinds of per- 
io missions (FIG. 2). While three kinds are adapted from exist- 
ing work [7, 12] we recently proposed lull and pure permis- 
sions [3]. State guarantees and temporary state information 
increase the usefulness of “weak” (share and pure) permis- 
sions. Permission splitting and joining is flexible enough to 
15 model temporary aliasing on the stack (during method calls) 
and in the heap (e.g., in pipes and iterators). Permission-based 
state invariants enable reasoning about protocol implementa- 
tions. We handle inheritance based on frames [12] and permit 
dynamic dispatch within objects for convenience methods. 
20 4. Formal Language 

This section formalizes an object-oriented language with 
protocol specifications. We briefly introduce expression and 
class declaration syntax before defining state spaces, access 
permissions, and permission-based specifications. Finally, 
25 we discuss handling of inheritance and enforcement of behav- 
ioral subtyping. 

4.1 Syntax 

FIG. 13 shows the syntax of a simple class-based object- 
oriented language. The language is inspired by Featherweight 
30 Java (FJ, [24]); we will extend it to include typestate protocols 
in the following subsections. We identity classes (C), meth- 
ods (m), and fields (f) with their names. As usual, x ranges 
over variables including the distinguished variable this for the 
receiver object. We use an overbar notation to abbreviate a list 
35 of elements. For example, x:T=x x :T 1? . . . , x n T w . Types (T) in 
our system include Booleans (bool) and classes. 

Programs are defined with a list of class declarations and a 
main expression. A class declaration CL gives the class a 
unique name C and defines its fields, methods, typestates, and 
40 state invariants. A constructor is implicitly defined with the 
class’s own and inherited fields. Fields (F) are declared with 
their name and type. Each field is mapped into a part of the 
state space n that can depend on the field (details in section 
5.2). A method (M) declares its result type, formal param- 
45 eters, specification and a body expression. State refinements 
R will be explained in the next section; method specifications 
MS and state invariants N are deferred to section 4.4. 

We syntactically distinguish pure terms t and possibly 
effectful expressions e. Arguments to method calls and object 
50 construction are restricted to terms . This simplifies reasoning 
about effects [30, 9] by making execution order explicit. 

Notice that we syntactically restrict field access and assign- 
ments to fields of the receiver class. Explicit “getter” and 
“setter” methods can be defined to give other objects access to 
55 fields. Assignments evaluate to the previous field value. 

4.2 State Spaces 

State spaces are formally defined as a list of state refine- 
ments (see FIG. 13). A state refinement (R) refines an existing 
state in a new dimension with a set of mutually exclusive 
60 sub -states. We use s and d to range over state and dimension 
names, respectively. A node n in a state space can be a state or 
dimension. State refinements are inherited by subclasses. We 
assume a root state alive that is defined in the root class 
Object. 

65 We define a variety of helper judgments for state spaces in 
FIG. 14. refinements (C) determines the list of state refine- 
ments available in class C. Cl -A wf defines well -formed state 
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assumptions. Assumptions A combine states and are defined 
in FIG. 15 . Conjunctive assumptions have to cover orthogo- 
nal parts of the state space. Cl-n^n defines the substrate 
relation for a class. Cl -A # A defines orthogonality of state 
assumptions. A and A are orthogonal if they refer to different 5 
(orthogonal) state dimensions. CI-A-< n defines that a state 
assumption A only refers to states underneath a root node n. 
Cl-A«n finds the tightest such n. 

4.3 Access Permissions 

Access permissions p give references permission to access 
an object. Permissions to objects are written access (r, n, g, k, 

A) (FIG. 15 ). (We wrote perm(r, n, g) in A before.) The 
additional parameter k allows us to uniformly represent all 
permissions as explained below. 15 

Permissions are granted to references r. References can be 
variables, locations, and fields. 

Permissions apply to a particular subtree in the space of r 
that is identified by its root node n. It represents a state 
guarantee (section 3). Other parts of the state space are unaf- 20 
fected by the permission. 

The fraction function g tracks for each node on the path 
from n to alive a symbolic fraction [6]. The fraction function 
keeps track of how often permissions were split at different 
nodes in the state space so they can be coalesced later (see 25 
section 5.5). 

The subtree fraction k encodes the level of access granted 
by the permission. k>0 grants modifying access. k<l implies 
that other potentially modifying permissions exist. Fraction 
variables z are conservatively treated as a value between 0 and 30 
1, i.e., 0<z<l. 

A state assumption A expresses state knowledge within the 
permission’s subtree. Only full permissions can permanently 
make state assumptions until they modify the object’s state 
themselves. For weak pennissions, the state assumption is 35 
temporary, i.e., lost after any effectful expression (because 
the object’s state may change without the knowledge of r). 

We can encode unique, full, share, and pure permissions as 
follows. In our formal treatment we omit immutable permis- 
sions, but it is straightforward to encode them with an addi- 40 
tional “bit” that distinguishes immutable and share permis- 
sions. 

unique(r, n, g) in A=access(r, n, {g, nl— > 1 }, 1> A) 
full(r, n, g) in A=access(r, n, g, 1, A) 

share(r, n, g, k) A=access(r, n, g, k, A) (0<k<l) 45 

pure(n, n, g) in A=access (r, n, g, 0, A) 

4.4 Permission-Based Specifications 

We combine atomic permissions (p) and facts about Bool- 
ean values (q) using linear logic connectives (FIG. 15 ). We 
also include existential (3z: H.P) and universal quantification 50 
of fractions (Vz:H.P) to alleviate programmers from writing 
concrete fraction functions in most cases. We type all expres- 
sions as an existential type (E). 

Method specifications. Methods are specified with a linear 
implication (- 0 ) of predicates (MS). The left-hand side of the 55 
implication (method pre-condition) may refer to method 
receiver and formal parameters. The right-hand side (post- 
condition) existentially quantifies the method result (a similar 
technique is used in Vault [11]). We refer to the receiver with 
this and usually call the return value result. 60 

State invariants. We decided to use linear logic predicates 
for state invariants as well (N). In general, several of the 
defined state invariants will have to be satisfied at the same 
time. This is due to our hierarchical state spaces. Each class 
declares an initialization predicate and a start state (I) that are 65 
used for object construction (instead of an explicit construc- 
tor). 
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4.5 Handling Inheritance 

Permissions give access to a particular frame, usually the 
virtual frame (see section 3.2) of an object. Permissions to the 
virtual frame are called object pennissions. Because of sub- 
typing, the precise frame referenced by an object permission 
is statically unknown. 

references r::= . . . Isuperlthis /r 

To handle inheritance, we distinguish references to the 
receiver’s “current” frame (this /r ) and its super- frame (super). 
Permissions for these “special” references are called frame 
permissions. A this^ pennission grants access to fields and 
can be used in method specifications. Permissions for super 
are needed for super-calls and are only available in state 
invariants. All methods requiring a this /r permission must be 
overridden because such methods rely on being defined in a 
particular frame to access its fields. 

4.6 Behavioral Subtyping 

Subclasses should be allowed to define their own specifi- 
cations, e.g., to add precision or support additional behavior 
[4] . However, subclasses need to be behavioral subtypes [29] 
of the extended class. Our system enforces behavioral sub- 
typing in two steps. Firstly, state space inheritance conve- 
niently guarantees that states of subclasses always corre- 
spond to states defined in superclasses [4]. Secondly, we 
make sure that every overriding method’s specification 
implies the overridden method’s specification [4] using the 
override judgment (FIG. 17 ) that is used in checking method 
declarations. This check leads to method specifications that 
are contra- variant in the domain and co-variant in the range as 
required by behavioral subtyping. 

5. Modular Typestate Verification 

This section describes a static modular typestate checking 
technique for access permissions similar to conventional 
typechecking. It guarantees at compile-time that protocol 
specifications will never be violated at runtime. We empha- 
size that our approach does not require tracking typestates at 
run time. 

A companion technical report contains additional judg- 
ments and a soundness proof for a fragment of the system 
presented in this disclosure [5]. The fragment does not 
include inheritance and only supports permissions for objects 
as a whole. State dimensions are omitted and specifications 
are deterministic. The fragment does include full, share, and 
pure permissions with fractions and temporary state informa- 
tion. 

5.1 Permission Tracking 

We permission-check an expression e with the judgment 
T;A'- c i e:3x:T.P\€. This is read as, “in valid context T and 
linear context A, an expression e executed within receiver 
class C has type T, yields permissions P, and affects fields €”. 
Permissions A are consumed in the process. We omit the 
receiver C where it is not required for checking a particular 
syntactic form. The set € keeps track of fields that were 
assigned to, which is important for the correct handling of 
permissions to fields. It is omitted when empty. The marker i 
in the judgment can be a 0 or 1 where i=l indicates that states 
of objects in the context may change during evaluation of the 
expression. This will help us reason about temporary state 
assumptions. A combination of markers with iVj is 1 if at least 
one of the markers is 1 . 

valid contexts T::=*ir,x:Tir,z:Hir,q 

linear contexts A::=*IA,P 
effects e::=*l€,f 

Valid and linear contexts distinguish valid (permanent) 
information (T) from resources (A). Resources are tracked 
linearly, forbidding their duplication, while facts can be used 
arbitrarily often. (In logical terms, contraction is defined for 



US 8,327,327 B2 


17 

facts only). The valid context types object variables, fraction 
variables, and location types and keeps track of facts about 
terms q. Fraction variables are tracked in order to handle 
fraction quantification correctly. The linear context holds cur- 
rently available resource predicates. 

The judgment T I -t:T types terms. It includes the usual rule 
for subsumption based on nominal subtyping induced by the 
extends relation (FIG. 17 ). Term typing is completely stan- 
dard and can be found in the companion report. The compan- 
ion report also includes rules for formally typing fractions 
and fraction functions [5]. 

Our expression checking rules are syntax-directed up to 
reasoning about permissions. Permission reasoning is 
deferred to a separate judgment T;AI-P that uses the rules of 
linear logic to prove the availability of permissions P in a 
given context. This judgment will be discussed in section 5.5. 
Permission checking rules for most expressions appear in 
FIG. 16 and are described in turn. Packing, method calls, and 
field assignment are discussed in following subsections. 
Helper judgments are summarized in FIG. 17 . The notation 
[t/r]e substitutes t for occurrences of r in e. 

P-TERM embeds terms. It formalizes the standard logical 
judgment for existential introduction and has no effect on 
existing objects. 

P-FIELD checks field accesses analogously. 

P-NEW checks object construction. The parameters 
passed to the constructor have to satisfy initialization predi- 
cate P and become the object’s initial field values. The new 
existentially quantified object is associated with a unique 
permission to the root state that makes state assumptions 
according to the declared start state A. Object construction 
has no effect on existing objects. 

The judgment init (FIG. 17 ) looks up initialization predi- 
cate and start state for a class. The start state is a conjunction 
of states (FIG. 15 ). The initialization predicate is the invariant 
needed for the start state. 

P-IF introduces non-determinism into the system, reflected 
by the disjunction in its type. We make sure that the predicate 
is of Boolean type and then assume its truth (falsehood) in 
checking the then (else) branch. This approach lets branches 
make use of the tested condition. 

P-Let checks a let binding. The linear context used in 
checking the second subexpression must not mention fields 
affected by the first expression. This makes sure that outdated 
field permissions do not “survive” assignments or packing. 
Moreover, temporary state information is dropped if the first 
subexpression has side effects. 

A program consists of a list of classes and a main expres- 
sion (P-PROG, FIG. 16 ). As usual, the class table CL is 
globally available. The main expression is checked with ini- 
tially empty contexts. The judgment CL ok (P-CLASS) 
checks a class declaration. It checks fields, states, and invari- 
ants for syntactic correctness (omitted here) and verifies con- 
sistency between method specifications and implementations 
using the judgment M ok in C. P-METH assumes the speci- 
fied pre-condition of a method (i.e., the left-hand side of the 
linear implication) and verifies that the method’s body 
expression produces the declared post-condition (i.e., the 
right-hand side of the implication). Conjunction with T drops 
excess permissions, e.g., to dead objects. The override judg- 
ment concisely enforces behavioral subtyping (see section 
4.6). A method itself is not a linear resource since all 
resources it uses (including the receiver) are passed in upon 
invocation. 

5.2 Packing and Unpacking 

We use a refined notion of unpacking [ 1 2] to gain access to 
fields: we unpack and pack a specific permission. The access 
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we gain reflects the permission we unpacked. Full and shared 
permissions give modifying access, while a pure permission 
gives read-only access to underlying fields. 

To avoid inconsistencies, objects are always fully packed 
5 when methods are called. To simplify the situation, only one 
permission can be unpacked at the same time. Intuitively, we 
“focus” [13] on that permission. This lets us unpack share like 
full permissions, gaining full rather than shared access to 
underlying fields (if available). The syntax for packing and 
10 unpacking is as follows. 

expressions e::= . . . lunpack(K, k, A) in el pack to A in 
e 

5 Packing and unpacking always affects the receiver of the 
currently executed method. The unpack parameters express 
the programmer’s expectations about the permission being 
unpacked. For simplicity, an explicit subtree fraction k is part 
of unpack expressions. It could be inferred from a program- 
20 mer-provided permission kind, e.g., share. 

Typechecking. For pack to work properly we have to 
“remember” the permission we unpacked. Therefore we 
introduce unpacked as an additional linear predicate. 

permissions p::= . . . Iimpacked(n, g, k, A) 

The checking rules for packing and unpacking are given in 
FIG. 19 . Notice that packing and unpacking always affects 
permissions to this^. (We ignore substitution of this with an 
object location at runtime here.) 

30 P-UNPACK first derives the permission to be unpacked. 
The judgment inv determines a predicate for the receiver’ s 
fields based on the permission being unpacked. It is used 
when checking the body expression. An unpacked predicate 
is added into the linear context. We can prevent multiple 
35 permissions from being unpacked at the same time using a 
straightforward dataflow analysis (omitted here). 

P-PACK does the opposite of P-UNPACK. It derives the 
predicate necessary for packing the unpacked permission and 
then assumes that permission in checking the body expres- 
40 sion. The new state assumption A can differ from before only 
if a modifying permission was unpacked. Finally, the rule 
ensures that permissions to fields do not “survive” packing. 

Invariant transformation. The judgment inv c (n, g, k, A) 
determines what permissions to fields are implied by a per- 
45 mission access(this^ r n, g, k, A) for a frame of class C. It is 
defined in FIG. 18 and uses a purify function (FIG. 20 ) to 
convert arbitrary into pure permissions. 

Unpacking a full or shared permission with root node n 
yields purified permissions for nodes “above” n and includes 
50 invariants following from state assumptions as -is. Con- 
versely, unpacking a pure permission yields completely puri- 
fied permissions. 

5.3 Calling Methods 

Checking a method call involves proving that the method’ s 
55 pre-condition is satisfied. The call can then be typed with the 
method’s post-condition. 

Unfortunately, calling a method can result into reentrant 
callbacks. To ensure that objects are consistent when called 
we require them to be fully packed before method calls. This 
60 reflects that aliased objects always have to be prepared for 
reentrant callbacks. 

This rule is not a limitation because we can always pack to 
some intermediate state although it may be inconvenient in 
practice. Notice that such intermediate packing obviates the 
65 need for adoption while allowing focus [13]: the intermediate 
state represents the situation where an adopted object was 
taken out of the adopting object. Inferring intermediate states 
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as well as identifying where reentrant calls are impossible 
(intermediate packing avoidance) are important areas for 
future research. 

Virtual calls. Virtual calls are dynamically dispatched (rule 
P-CALL). In virtual calls, frame and object permissions are 5 
identical because object permissions simply refer to the 
object’s virtual frame. This is achieved by substituting the 
given receiver for both this and this /r . 

Super calls. Super calls are statically dispatched (rule 
P-SUPER). Recall that super is used to identify permissions 10 
to the super-frame. We substitute super only for this^. We 
omit a substitution of this for the receiver (this again) for 
clarity. 

5.4 Field Assignments 

Assignments to fields change the state of the receiver’s 15 
current frame. We point out that assignments to a field do not 
change states of objects referenced by the field. Therefore 
reasoning about assignments mostly has to be concerned with 
preserving invariants of the receiver. The unpacked predicates 
introduced in section 5.2 help us with this task. 

Our intuition is that assignment to a field requires unpack- 
ing the surrounding object to the point where all states that 
refer to the assigned field in their invariants are revealed. 
Notice that the object does not have to be unpacked com- 
pletely in this scheme. For simplicity, each field is annotated 25 
with the subtree that can depend on it (FIG. 13). Thus we 
interpret subtrees as data groups [27]. 

The rule P- ASSIGN (FIG. 19) assigns a given object t to a 
field f and returns the old field value as an existential x'. This 
preserves information about that value. The rule verifies that 
the new object is of the correct type and that a suitable full or 
share permission is currently unpacked. By recording an 
effect on f z we ensure that information about the old field 
value cannot “flow around” the assignment (which would be 
unsound). 

5.5 Permission Reasoning with Splitting and Joining 

Our permission checking rules rely on proving a predicate 

P given the current valid and linear resources, written T ; Al -P. 

We use standard rules for the decidable multiplicative-addi- 
tive fragment of linear logic (MALL) with quantifiers that 40 
only range over fractions [28]. Following Boy land [7] we 
introduce a notion of substitution into the logic that allows 
substituting a set of linear resources with an equivalent one. 


r ; a vP p 

— — SUBST 


The judgment P^ P’ defines legal substitutions. We use 50 
substitutions for splitting and joining permissions (FIG. 21). 
The symbol indicates that transformations are allowed in 
both directions. SYM and ASYM generalize the rules from 
section 2. Most other rules are used to split permissions for 
larger subtrees into smaller ones and vice versa. A detailed 55 
explanation of these rules can be found in the companion 
report [5]. 

Our splitting and joining rules maintain a consistent set of 
permissions for each object so that no permission can ever 
violate an assumption another permission makes. Fractions 60 
of all permissions to an object sum up to (at most) 1 for every 
node in the object’s state space. 

5.6 Example 

To illustrate how verification proceeds, FIG. 22 shows the 
fill method from BufferedlnputStream (FIG. 12) written in 65 
our core language. As can be seen, we need an intermediate 
state reads and a marker field reading that indicate an ongoing 
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call to the underlying stream. We also need an additional state 
refinement to specify an internal method replacing the while 
loop in the original implementation. (We assume that this /r 
permissions can be used for calls to private methods.) 

Maybe surprisingly, we have to reassign field values after 
super, read ( ) returns. The reason is that when calling super 
we lose temporary state information for this. Assignment 
re-establishes this information and lets us pack properly 
before calling doFill recursively or terminating in the cases of 
a full buffer or a depleted underlying stream. 

It turns out that these re-assignments are not just an incon- 
venience caused by our method but point to a real problem in 
the Java standard library implementation. We could imple- 
ment a malicious underlying stream that calls back into the 
“surrounding” BufferedlnputStream object. This call 
changes a field, which causes the buffer’s invariant on count 
to permanently break, later on resulting in an undocumented 
array bounds exception when trying to read behind the end of 
the buffer array. 

Because fill operates on a share permission our verification 
approach forces taking into account possible field changes 
through reentrant calls with other share permissions. (This is 
precisely what our malicious stream does.) We could avoid 
field re-assignments by having read require a full permission, 
thereby documenting that reentrant (modifying) calls are not 
permitted for this method. 

6. Related Work 

In previous work we proposed more expressive typestate 
specifications [4] that can be verified with the approach pre- 
sented in this paper. We also recently proposed full and pure 
permissions and applied our approach to specifying full Java 
iterators [3]. Verification of protocol compliance has been 
studied from many different angles including type systems, 
abstract interpretation, model checking, and verification of 
general program behavior. Aliasing is a challenge for all of 
these approaches. 

The system that is perhaps closest to our work is Fugue 
[12], the first modular typestate verification system for 
object-oriented software. Methods are specified with a deter- 
ministic state transition of the receiver and pre-conditions on 
arguments. Fugue’s type system tracks objects as “not 
aliased” or “maybe aliased.” Leveraging research on “alias 
types” [33] (see below), objects typically remain “not 
aliased” as long as they are only referenced on the stack. Only 
“not aliased” objects can change state; once an object 
becomes “maybe aliased” its state is permanently fixed 
although fields can be assigned to if the object’s abstract 
typestate is preserved. 

Our approach supports more expressive method specifica- 
tions based on linear logic [18]. Our verification approach is 
based on “access permissions” that permit state changes even 
in the presence of aliases (multiple references from other 
clients). We extend several ideas from Fugue to work with 
access permissions including state invariants, packing, and 
frames. Fugue’s specifications are expressible with our sys- 
tem [4]. Fugue’s “not aliased” objects can be simulated with 
unique permissions for alive and “maybe aliased” objects 
correspond to share permissions with state guarantees. There 
is no equivalent for state dimensions, temporary state 
assumptions, full, immutable, and pure permissions, or per- 
missions for object parts in Fugue. 

Verification of protocol compliance has also been 
described as “resource usage analysis” [23]. Protocol speci- 
fications have been based on very different concepts includ- 
ing typestates [34, 1 1 , 25], type qualifiers [16], size properties 
[9], direct constraints on ordering [23, 35], and type refine- 
ments [30, 10]. None of the above systems can verify imple- 
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mentations of obj ect-oriented protocols like our approach and 
only two [35, 10] target object-oriented languages. Effective 
type refinements [30] employ linear logic reasoning but can- 
not reason about protocol implementations and do not sup- 
port aliasing abstractions. Hob [25] verifies data structure 
implementations for a procedural language with static mod- 
ule instantiation based on typestate-like constraints using 
shape analyses. In Hob, data can have states, but modules 
themselves cannot. In contrast, we can verify the implemen- 
tation of stateful objects that are dynamically allocated and 
support aliasing with permissions instead of shape analysis. 
Finally, concurrent work on Java(X) proposes “activity anno- 
tations” that are comparable to full, share, and pure permis- 
sions for whole objects that can be split but not joined. Similar 
to effective type refinements, state changes can be tracked for 
a pre-defined set of types, but reasoning about the implemen- 
tation of these types is not supported. To our knowledge, none 
of the above systems supports temporary state information. 

Because programming with linear types [36] is very incon- 
venient, a variety of relaxing mechanisms were proposed. 
Uniqueness, sharing, and immutability (sometimes called 
read-only) [7] have recently been put to use in resource usage 
analysis [23, 9]. Alias types [33] allow multiple variables to 
refer to the same object but require a linear token for object 
accesses that can be borrowed [7] during function calls. 
Focusing can be used for temporary state changes of shared 
objects [13, 16, 2]. Adoption prevents sharing from leaking 
through entire object graphs (as in Fugue [12]) and allows 
temporary sharing until a linear adopter is deallocated [13]. 
All these techniques need to be aware of all references to an 
object to change its state. 

Access permissions allow state changes even if objects are 
aliased from unknown places. Moreover, access permissions 
give fine-grained access to individual data groups [27] . States 
and fractions [6] let us capture alias types, borrowing, adop- 
tion, and focus with a single mechanism. Sharing of indi- 
vidual data groups has been proposed before [7], but it has not 
been exploited for reasoning about object behavior. In Boy- 
land’s work [6], a fractional permission means immutability 
(instead of sharing) in order to ensure noninterference of 
permissions. We use permissions to keep state assumptions 
consistent but track, split, and join permissions in the same 
way as Boyland. 

Global approaches are very flexible in handling aliasing. 
Approaches based on abstract interpretation (e.g., [1, 19, 14]) 
typically verify client conformance while the protocol imple- 
mentation is assumed correct. Sound approaches rely on a 
global aliasing analysis [1,14]. Likewise, most model check- 
ers operate globally (e.g., [21]) or use assume-guarantee rea- 
soning between coarse-grained static components [17, 22]. 
The Magic tool checks individual C functions but has to inline 
user-provided state machine abstractions for library code to 
accommodate aliasing [8]. The above analyses typically run 
on the complete code base once a system is fully implemented 
and are very expensive. Our approach supports developers by 
checking the code at hand like a typechecker. Thus the ben- 
efits of our approach differ significantly from global analyses. 

Recently, there has been progress in inferring typestate 
protocols in the presence of aliasing [31], which we believe 
could be fruitfully combined with our work to reduce initial 
annotation burden. 

Finally, general approaches to specifying program behav- 
ior [26, 15, 2] can be used to reason about protocols. The JML 
[26] is very rich and complex in its specification features; it is 
more capable than our system to express object behavior (not 
just protocols), but also potentially more difficult to use due to 
its complexity. Verifying JML specifications is undecidable in 


22 

the general case. Tools like ESC/Java [15] can partially check 
JML specifications but are unsound because they do not have 
a sound methodology for handling aliasing. Spec# is compa- 
rable in its complexity to the JML and imposes similar over- 

5 head. The Boogie methodology allows sound verification of 
Spec# specifications but requires programs to follow an own- 
ership discipline [2]. 

Our system is much simpler than these approaches, focus- 
ing as it does on protocols, and it is designed to be decidable. 

to Our treatment of aliasing makes our system sound, where 
ESC/Java is not. While the treatment of aliasing in our system 
does involve complexity, it gives the programmer more flex- 
ibility than Boogie’s method while remaining modular and 
sound. Because it is designed for protocol verification in 

15 particular, our system will generally impose smaller specifi- 
cation overhead than the JML or Spec#. 
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What is claimed is: 

1. A method for statically checking an object-oriented 
computer program module, comprising: 

identifying objects within a computer program module, at 
least one of said objects having a plurality of references 
thereto; 

imposing a discipline of permissions to the objects identi- 
fied within the computer program module that enables 
tracking, from among a discrete set of changeable states, 
a subset of states each object might be in; 
determining whether the imposed permissions are violated 
by a potential reference to any of the identified objects; 
and 

outputting the result of said determining. 

2 . The method of claim 1 , wherein said imposing a disci- 
pline of permissions includes imposing permissions that per- 
mit multiple independent references to an object. 

3. The method of claim 1 wherein said imposing a disci- 
pline of permissions includes imposing a permission selected 
from the group comprising: 

a permission allowing a read-only reference to an object, 
where other references can read and write to the object; 
a permission allowing a read/write reference to an object, 
where all other references to the object are read-only; 
a permission allowing a read-only reference to an object, 
where all other references to the object are also read- 
only; 

a permission allowing a single reference to an object; and 
a permission allowing a read/write reference to an object, 
where other references to the object can also be read/ 
write references. 

4 . The method of claim 1, wherein said determining is 
based on each of said objects assuming states that change 
perceptibly and non-monotonically within a guaranteed state 
space. 

5 . The method of claim 4 wherein said imposing a disci- 
pline of permissions comprises imposing permissions that 
can be associated with a fraction of an object. 

6 . The method of claim 1 wherein said determining is based 
on each of said objects having a state represented by a hier- 
archical state machine. 

7 . The method of claim 1 , wherein said determining is 
based on said objects having a superclass state and a subclass 
state, and wherein said superclass state and said subclass may 
be different. 

8. A method for statically checking an object-oriented 
computer program module, comprising: 

identifying objects within a computer program module; 
partitioning identified objects into a plurality of dimen- 
sions each dimension assigned to a client; 
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each client independently tracking, from among a discrete 
set of changeable states, a subset of states each object 
might be in within that client’s dimension; 
imposing a discipline of permissions in which the opera- 
tions that a client can invoke involving an object are 5 
limited to those operations in which the invoked opera- 
tion changes the state of the object only in that client’s 
dimension; 

determining whether the imposed permissions are vio- 
lated; and 

outputting the result of said determining. 

9. The method of claim 8 wherein said imposing a disci- 
pline of permissions includes imposing a permission selected 
from the group comprising: 

a permission allowing a read-only reference to an object, 
where other references can read and write to the object; 
a permission allowing a read/write reference to an object, 
where all other references to the object are read-only; 
a permission allowing a read-only reference to an object, ^ 
where all other references to the object are also read- 
only; 

a permission allowing a single reference to an object; and a 
permission allowing a read/write reference to an object, 
where other references to the object can also be read/ 
write references . 

10. The method of claim 8, wherein said determining is 
based on each of said objects assuming states that change 
perceptibly and non-monotonically within a guaranteed state 
space. 

11. The method of claim 8, wherein said determining is 
based on each of said objects having a state represented by a 
hierarchical state machine. 

12. The method of claim 8, wherein said determining is 
based on said objects having a superclass state and a subclass 35 
state, and wherein said superclass state and said subclass may 
be different. 

13. A method for statically checking an object-oriented 
computer program module, comprising: 

identifying objects within a computer program module; 
imposing a discipline of permissions to the objects identi- 
fied within the computer program module such that for 
each object, only one client may have read/write permis- 
sion to said object, track said object’s state from among 
a discrete set of changeable states, and perform any legal 
operation on said object given said object’s current state 
while all other clients may have read-only access to said 
object, and can perform only operations that do not 
affect said object’s state and are legal given the client’s 
knowledge of said object’s current state; 
determining whether the imposed permissions are vio- 
lated; and 

outputting the result of said determining. 

14. The method of claim 13 wherein said imposing a dis- 
cipline of permissions includes imposing at least one addi- 
tional discipline selected from the group comprising: 

a permission allowing a single reference to an object; and 
a permission allowing a read/write reference to an object, 
where other references to the object can also be read/ 
write references. 


26 

15. The method of claim 13, wherein said determining is 
based on each of said objects assuming states that change 
perceptibly and non-monotonically within a guaranteed state 
space. 

16. The method of claim 14, wherein said imposing a 
discipline of permissions comprises imposing permissions 
that can be associated with a fraction of an object. 

17. The method of claim 13, wherein said determining is 
based on each of said objects having a state represented by a 
hierarchical state machine. 

18. The method of claim 13, wherein said determining is 
based on said objects having a superclass state and a subclass 
state, and wherein said superclass state and said subclass may 
be different. 

19. A method for statically checking an object-oriented 
computer program module, comprising: 

identifying objects within a computer program module, 
said objects having discrete states that change percepti- 
bly and non-monotonically within a guaranteed state 
space; 

imposing a discipline of permissions to the objects identi- 
fied within the computer program module such that a 
plurality of clients can each have a permission that 
enables tracking a subset of states each object might be 
in; 

determining whether the imposed permissions are vio- 
lated; and 

outputting the result of said determining. 

20. A method for statically checking an object-oriented 
computer program module, comprising: 

identifying objects within a computer program module, at 
least one of said objects having a plurality of references 
thereto; 

imposing a discipline of permissions to the objects identi- 
fied within the computer program module that enables 
tracking, from among a discrete set of changeable states 
represented by a hierarchical state machine, a subset of 
states each object might be in; 

determining whether the imposed permissions are violated 
by a potential reference to any of the identified objects; 
and 

outputting the result of said determining. 

21. A method for statically checking an object-oriented 
computer program module, comprising: 

identifying objects within a computer program module, at 
least one of said objects having a plurality of references 
thereto; 

imposing a discipline of permissions to the objects identi- 
fied within the computer program module that enables 
tracking, from among a discrete set of changeable states 
including a superclass state and a subclass state which 
may differ, a subset of states each object might be in; 

determining whether the imposed permissions are violated 
by a potential reference to any of the identified objects; 
and 

outputting the result of said determining. 

22. The method of claim 1, wherein said plurality of refer- 
ences are active at a particular execution point. 





